<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>WindowBuilder Pro FAQ</title>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<link href="../book.css" rel="stylesheet" type="text/css">
</head>

<body>
		<h1>WindowBuilder Pro FAQ</h1>
		<table border="0" width="900" cellspacing="0" cellpadding="0">
			<tr>
				<td>The following are frequently asked questions about WindowBuilder:&nbsp;<ul>
			<li><a href="#UpdateManager">What should I do if I'm getting errors 
			using the Update Manager?</a></li><li><a href="#OtherGUIBuilders">Can 
			WindowBuilder Pro edit windows created 
	with JBuilder, VA Java, NetBeans, VisualCafe, etc.?</a></li>
			<li><a href="#CreatedByHand">Can WindowBuilder Pro edit windows that have been 
	created by hand?</a></li>
			<li><a href="#Refactor">Can I refactor or otherwise modify the 
			WindowBuilder Pro 
	generated code?</a></li>
			<li><a href="#SpecialTags">Why doesn't WindowBuilder Pro surround generate code with 
	special tags or mark it as read-only?</a></li>
			<li><a href="#CantParse">Are there any specific constructs that 
			WindowBuilder Pro 
	can't parse?</a></li>
			<li><a href="#Constructor">Why does WindowBuilder Pro generate in 
	the constructor?</a></li>
			<li><a href="#CustomWidgets">Can WindowBuilder Pro use custom&nbsp;widgets?</a></li>
			<li><a href="#InstantiationException">What should I do if I 
			encounter an InstantiationException or other error when using a custom widget?</a></li>
			<li><a href="#Installation">What should I do if WindowBuilder Pro does not appear 
	after installation?</a></li>
			<li><a href="#DoesNotWork">What should I do if WindowBuilder Pro does not 
			work after installation?</a></li>
			<li><a href="#DesignTab">What can I do if I don't see the Design tab 
	when I edit a window?</a></li>
			<li><a href="#Exception">What should I do if I encounter an exception using
			WindowBuilder Pro?</a></li>
			<li><a href="#ParsingError">What should I do if I encounter Parsing 
			Error?</a></li>
			<li><a href="#OutOfMemoryError">What should I do if I encounter an 
	OutOfMemoryError using WindowBuilder Pro?</a></li>
			<li><a href="#NoSuchMethodError">What should I do if I encounter an 
			NoSuchMethodError or </a><a href="#NoClassDefFoundError">NoClassDefFoundError using 
			WindowBuilder Pro?</a></li>
			<li><a href="#UnsupportedClassVersionError">What should I do if I encounter an 
			UnsupportedClassVersionError using WindowBuilder Pro?</a></li>
			<li><a href="#UnsatisfiedLinkError">What should I do if I encounter an 
	UnsatisfiedLinkError when launching my SWT application?</a></li>
			<li><a href="#Linux">How should WindowBuilder Pro be configured to work on 
			Linux?</a></li>
			<li><a href="#SuSELinux">What should I do if I have problems running 
			under SuSE Linux?</a></li>
			<li><a href="#LinuxFlashing">How can I prevent 
			the preview window from flashing under Linux using Metacity</a></li>
		</ul>
				<h2>What should I do if I'm 
				getting errors using the Update Manager?</h2>
				<p>If you encounter some sort of Eclipse Update Manager failure 
				with messages such as &quot;Downloaded stream not a valid archive&quot; or 
				&quot;Problems downloading artifact&quot;, this is caused by a common, 
				well known flaw in the Eclipse Update Manager with a very simple 
				solution: wait five minutes, restart Eclipse, and try it again. 
				Re-starting Eclipse is necessary as Eclipse will actually cache 
				the failure and will refuse to try again during the same 
				session. If you try this a couple of times and the problem 
				persists, it could point to a more rare and troubling problem 
				with a corrupted Eclipse p2 plug-in cache. The next thing to try 
				in that case would be to re-install Eclipse and try again with a 
				new, clean Eclipse environment. If that does not help, send a 
				screen shot of your &quot;Help &gt; About &gt; Installation Details &gt; 
				Installed Software&quot; page as well as a copy of your complete 
				&quot;Help &gt; About &gt; Installation Details &gt; Configuration&quot; to support. 
				You can also try installing into a new, clean Eclipse 
				environment using one of the ZIP install options on the product 
				download page.</p>
				<h2><a name="OtherGUIBuilders"></a>Can WindowBuilder Pro 
			edit windows created with JBuilder, VA Java, NetBeans, VisualCafe, 
			etc.?</h2>
		<p>Yes. Most GUI builders in the world will only read and write the 
			code that they themselves create. WindowBuilder Pro is an exception to 
			that rule. It can read and edit not only the code it creates, but 
			also a great deal of code generated by other GUI builders (&gt;95%). We 
			have had very good success with code generated by JBuilder, NetBeans, 
			Visual Cafe, VA Java, the Eclipse VE, etc. If you come across a case 
			that does not work, send it to us for analysis. The more broken 
			examples that we can "fix", the better WindowBuilder Pro will get in the long 
			run (and the better chance you will have of salvaging your old code 
			as-is). Note that WindowBuilder Pro will edit any existing code in place 
			without changing its formatting. Any new widgets will be created 
			using WindowBuilder Pro's own code 
			generation preferences.</p>
		<h2 style="font-weight: bold"><a name="CreatedByHand"></a>Can 
		WindowBuilder Pro edit windows that have been created by hand?</h2>
		<p>Yes. Most GUI builders in the world will only read and write the 
			code that they themselves create. WindowBuilder Pro is an exception to 
			that rule. It can read and write not only the code it creates, but 
			also a great deal of code written by hand(&gt;90%). If you come across 
			a case that does not work, send it to us for analysis. The more 
			broken examples that we can "fix", the better WindowBuilder Pro will get in 
			the long run (and the better chance you will have of salvaging your 
			old code as-is).</p><p>Note that dynamic GUI code can not be rendered or edited. The
problem with dynamic code is that it generally relies on runtime
calculations that have no meaning at runtime. Widgets created in a loop
(where the loop parameters are passed in externally) are a good
example. Widgets created in conditionals where the value of the
conditional is not known until runtime are another example. Dynamic GUI
code constructed from the results of complex database queries is yet
another example.</p>
		<h2 style="font-weight: bold"><a name="Refactor"></a>Can I refactor 
			or otherwise modify the WindowBuilder Pro generated code?</h2>
		<p>Yes. The WindowBuilder Pro parser has a good understanding of basic 
			Java code and various Swing, SWT and other UI toolkit patterns patterns. As a result, it is 
			very refactoring friendly and very resilient in the face of hand 
			made changes. You can make changes or add code anywhere you like and 
		WindowBuilder Pro will reverse engineer it when possible. You can also 
			refactor the code in almost any conceivable way and WindowBuilder 
		Pro 
			will still be able to parse it and render it in the design view. For 
			example, use the tool to create a new Swing JFrame, add some 
			widgets, and then use the Eclipse refactoring tools to extract some 
			of the widgets into their own methods.</p>
		<h2 style="font-weight: bold;"><a name="SpecialTags"></a>Why doesn't 
			WindowBuilder Pro surround generate code with special tags or mark it as 
			read-only?</h2>
		<p>Using special tags or marking code read-only would 
			go against several of WindowBuilder Pro's major design goals. 
		WindowBuilder Pro does 
			not make any distinction between generated code and user-written 
			code. WindowBuilder Pro is designed to generated the same code that you would 
			write by hand and to make minimal changes to the source when you 
			make a change to the design view. WindowBuilder Pro never regenerates the 
			entire source for a file. If you change a single property, it will 
			change only a single line of code. That line of code could 
			theoretically be anywhere in the source file (including within lines 
			originally created by WindowBuilder Pro or within lines that you wrote by 
			hand).</p>
		<h2 style="font-weight: bold;"><a name="CantParse"></a>Are there any 
			specific constructs that WindowBuilder Pro can't parse?</h2>
		<p>Yes. Here are some examples of constructs that WindowBuilder Pro 
			does not yet handle:</p>
		<ul>
			<li>Re-use of GridBagConstraint objects across multiple widgets 
				(we support reusing the same variable but not the same objects)</li>
			<li>UI construction through the use of local 
				parameterized helper methods</li>
			<li>Multiple aliases (fields or local variables) referring to 
				the same component</li>
			<li>Multiple references to the same widget definition through 
			multiple invocations of the same helper method</li>
			<li>Dynamic GUI code based on runtime calculations</li>
		</ul>
		<h2 style="font-weight: bold;"><a name="Constructor"></a>Why does 
			WindowBuilder Pro generate widgets in the constructor?</h2>
		<p>WindowBuilder Pro can generate code into 
		any method that you 
			like. One of the key features of WindowBuilder Pro is its refactoring 
			friendliness. You can actually use any template that you want for 
			creating a new window (e.g., you don't need to use the wizards 
			supplied with WindowBuilder Pro). Alternatively, you can use the Eclipse refactoring commands to extract the components into a new method 
			(like createComponents()) and the tool will continue to work. Try 
			the following template for example:</p>
		<blockquote>
			<p><font face="Courier">import javax.swing.JFrame;<br>public class MyFrame extends JFrame {<br>&nbsp;&nbsp;&nbsp; public static void main(String args[]) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MyFrame frame = new MyFrame();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; frame.setVisible(true);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (Exception e) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e.printStackTrace();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; public MyFrame() {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; super();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; createComponents();<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; private void createComponents() {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setBounds(100, 100, 400, 300);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br>&nbsp;&nbsp;&nbsp; }<br>}</font></p>
		</blockquote>
		<p>If you start adding new widgets, 
			they will be added to the createComponents() method.</p>
		<h2 style="font-weight: bold;"><a name="CustomWidgets"></a>Can 
		WindowBuilder Pro use custom widgets?</h2>
		<p>Yes., with a few restrictions.</p><p>For Swing, any public JComponent subclass that has a 
			public, zero-argument constructor can be used (as required by the Java Bean spec). Custom properties are 
			derived through reflection by looking for getter/setter pairs of 
			known types. If a matching JavaBean class is defined and available, 
			it will be used for any custom properties. Custom JPanel subclasses 
			will show their subcomponents when placed in WindowBuilder Pro.&nbsp;</p><p>For 
			SWT, any public Control subclass that has a public, two-argument 
			constructor can be used (as is standard for all base SWT widgets). Custom properties are derived through 
			reflection by looking for getter/setter pairs of known types. SWT 
			does not yet define any kind of JavaBean interface, so no further 
			customization is available. Custom Composite subclasses will show 
			their subcomponents when placed in WindowBuilder Pro.</p><p>For other UI toolkits, any public Widget subclass that has a 
			public, zero-argument constructor can be used. Custom properties are 
			derived through reflection by looking for getter/setter pairs of 
			known types. Custom Composite subclasses 
			will show their subcomponents when placed in WindowBuilder Pro.&nbsp;</p><p>Note: the
Java Bean conventions (slightly modified for SWT) are important from a
GUI builder point of view as they establish a common, expected, and,
for the most part, self documenting API. If you create your own unique
constructors, your are, in effect, creating your own personal API which
makes it difficult for a GUI builder to reflectively interact with your
components. Generating code to a custom constructor API requires
knowledge of the API that generally is not provided by the component.
That requires hard coding knowledge of the component into the GUI
builder itself. </p>
		<p>Note: A component may rely on some runtime behavior that is 
		not possible at design time (such as accessing an application database 
		or some other file). Runtime specific behavior should be isolated (and 
		stubbed out as necessary) by wrappering the runtime specific code with a call to
		Beans.isDesignTime() which will answer true when the 
		component is loaded within WindowBuilder Pro and false at runtime.</p>
		<h2 style="font-weight: bold;"><a name="InstantiationException"></a>What should I do 
			if I encounter an InstantiationException or other error using a custom widget?</h2>
		<p>An InstantiationException means that WindowBuilder Pro 
		could not create an instance of a particular class. The most common 
		reason for this is that the component is not a <a href="#CustomWidgets">valid custom widget</a>. In order to be a valid Swing widget, a class must be a valid 
		Java Bean and have a public, zero-argument constructor. SWT 
		widgets must have a public two-argument constructor with parent 
		and style bits as the two arguments. To fix the problem, add the missing 
		constructor. Note: the
Java Bean conventions (slightly modified for SWT) are important from a
GUI builder point of view as they establish a common, expected, and,
for the most part, self documenting API. If you create your own unique
constructors, your are, in effect, creating your own personal API which
makes it difficult for a GUI builder to reflectively interact with your
components. Generating code to a custom constructor API requires
knowledge of the API that generally is not provided by the component.
That requires hard coding knowledge of the component into the GUI
builder itself.</p>
		<p>Another possible cause for this exception is some other 
		failure in the initialization code of the component. A component may 
		rely on some runtime behavior that is not possible at design time (such 
		as accessing an application database or some other file). Runtime 
		specific behavior should be isolated (and stubbed out as necessary) by 
		wrappering the runtime specific code with a call to
		<b>Beans.isDesignTime()</b> which will answer true when the 
		component is loaded within WindowBuilder Pro and false at runtime.</p>
		<p>More detail about the use of custom widgets is available 
		in <a href="#CustomWidgets">this FAQ entry</a>.</p>
		<h2 style="font-weight: bold;"><a name="Installation"></a>What should 
			I do if WindowBuilder Pro does not appear after installation?</h2>
		<p align="left">First, make sure that the WindowBuilder Pro plugins have 
		been installed properly. If you used the ZIP installation, make sure that the <b>
		WindowBuilder Pro</b> plugins 
		were unzipped to your eclipse/plugins or /dropins directory.&nbsp;</p>
				<p align="left"><span style="font-weight: bold;">If you are installing into Eclipse 3.4</span>, there is a bug in the new p2 update manager that does not uninstall bundles (see bug <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=232094">232094</a>). To workaround this&nbsp; try deleting the bundles.info
file from the /configuration/org.eclipse.equinox.simpleconfigurator
directory and restore the file from the Eclipse ZIP file. If deleting
the bundles.info was not sufficient, delete the entire /configuration
and /p2 directories from your eclipse directory and restore those
directories from the Eclipse ZIP file.</p>
		<p align="left">After restarting Eclipse, open the Eclipse preference 
			dialog and confirm that you see a
			<a href="preferences/index.html">WindowBuilder preference page</a>. 
		If <b>WindowBuilder Pro</b> still does not appear, check your Eclipse &quot;.log&quot; 
		file (found in your &lt;workspace&gt;/.metadata directory) for any recorded 
		exceptions and then contact support.If 
		no exceptions are present and <b>WindowBuilder Pro</b> is still not present, make 
		sure that you are using a properly configured Eclipse-based IDE. <b>
		WindowBuilder Pro</b> requires the complete <b>Eclipse SDK</b> to be present, and 
		will not load into an Eclipse subset (like EasyEclipse or the MyEclipse All-in-one 
		edition). The most important piece missing from some Eclipse 
		distributions is the Eclipse PDE (Plug-in Development Environment). You 
		can correct this problem by launching Eclipse and selecting <b>Help &gt; 
		Software Updates</b>. Select The Eclipse Project updates from 
		the list of sites and select the "<b>Eclipse Plug-in Development 
		Environment</b>&quot; to install. You may need to shutdown Eclipse and clean 
		your configuration directory as described above.</p>
		<h2 style="font-weight: bold;"><a name="DoesNotWork"></a>What should I do 
		if WindowBuilder Pro does not work after installation?</h2>
		<p>If WindowBuilder Pro fails to work properly (indicated by 
		throwing a random exception or showing a blank design view) after 
		installation when creating or editing a new window (or performing any 
		simple editing activity), you are likely experiencing an installation 
		problem. Try the following:</p>
		<ol>
			<li>
			Check that you have the correct version of 
			WindowBuilder Pro installed for your Eclipse environment. If you are 
			using Eclipse 3.6, use the latest WindowBuilder Pro build targeted at 
			Eclipse 3.6. Likewise, if you are using Eclipse 3.7, use the latest
			WindowBuilder Pro build targeted at Eclipse 3.7.</li>
			<li>
			Check that only one version of WindowBuilder Pro (one 
			set of *designer* plugins and features) is installed. If you have an 
			older version also installed (indicated by an earlier version 
			number), delete those plugins and features and repeat step number 
			two above. Make sure that you don't have WindowBuilder Pro installed 
			both locally within your Eclipse /plugins directory and 
			remotely through a .link file (check your Eclipse /links 
			directory).</li>
			<li>
			Check your project for classpath problems and your 
			code for compilation problems. If your file or your project 
			shows a red X, WindowBuilder Pro 
			may not be able to edit the file. Resolve the problem and open the 
			file again.</li>
			<li>
			Try refreshing and rebuilding your project using the
			<b>Project &gt; Clean</b> command.</li>
			<li>
			If the problem persists, check your Eclipse ".log" 
			file (found in your <b>&lt;workspace&gt;/.metadata</b> directory) 
			for any recorded exceptions and then contact support.</li>
			<li>
			If Eclipse locks up repeatedly, you might try 
			running Eclipse with the <b>-debug</b> command line option. You can 
			then press <b>Ctrl+Break</b> in the console to look at the thread 
			dump which may show where the system is locking up. Send that thread 
			dump to support.</li>
		</ol>
		<h2 style="font-weight: bold;"><a name="DesignTab"></a>What can I do 
			if I don't see the Design tab when I edit a window?</h2>
		<p>
<img border=0
src="features/images/open_with.gif" v:shapes="_x0000_i1032" align="right" hspace="5">Eclipse remembers the last editor type used with a 
			file. If you don't see the <b>Design</b> tab, that means that you are using the standard Eclipse 
		<b>Java Editor</b> 
			rather than the <b>
		<a href="features/editing_existing_window.html">WindowBuilder Editor</a></b>. Open the file with the
		<b>
		<a href="features/editing_existing_window.html">WindowBuilder Editor</a></b> and you will see both 
			the <b>Source</b> and <b>Design</b> tabs. Note that Eclipse will 
		only let you have a file open with one editor at a time, so you may need 
		to close any existing editor before opening it with the <b>
		<a href="features/editing_existing_window.html">WindowBuilder Editor</a></b>.</p>
				<p>
<img border=0 width=252 height=70
src="features/images/source_design.png" v:shapes="_x0000_i1033"></p>
		<h2 style="font-weight: bold;"><a name="Exception"></a>What should I 
			do if I encounter an exception using WindowBuilder Pro?</h2>
		<p>If a newer WindowBuilder Pro build is available than the one you 
			are using, please download the newer build and try and reproduce the 
			problem. If the problem has been reported in the past, there is a 
			good chance that it has already been fixed. If the problem still 
			exists, you should send your Eclipse ".log" file (found in your 
			<b>&lt;workspace&gt;/.metadata</b> directory) as well as any relevant test cases 
			to
			<a href="support/product_support.html">support</a>. 
		Including a <a href="support/test_cases.html">test case</a> that will 
			help us reproduce the problem is very important. The faster we can 
			reproduce the problem, the faster we can get you a fix. If we can't 
			reproduce a problem, there is little we can do to help you. </p>
		<p>Ideally, 
			the <a href="support/test_cases.html">test case</a> you send should be the same window you were editing 
			when the problem occurred (along with any supporting files needed to 
		compile it). If that is not possible (possibly because 
			you aren't allowed to send any code to a 3rd party), then you should 
			try to create a new, standalone test case that illustrates the same 
			problem. The best approach is to create a standalone test case by 
		removing all of the code that isn't relevant to the problem at hand 
		(e.g., keep deleting code until the problem goes away and then restore 
		that last code that was last deleted).</p>
		<h2 style="font-weight: bold;"><a name="ParsingError"></a>What should I do 
		if I encounter a Parsing Error?</h2>
		<p>As suggested by the message, this is error is caused by 
		a parsing problem. It has nothing to do with 
		licensing. Your Eclipse ".log" file (found in your 
		<b>&lt;workspace&gt;/.metadata</b> directory) should provide a hint as to the cause 
		of the parsing error. Send the log file as well as a test case to
			<a href="support/product_support.html">support</a> 
		(ideally the window you are trying to edit). Including a 
		<a href="support/test_cases.html">test case</a> that will 
			help us reproduce the problem is very important. The faster we can 
			reproduce the problem, the faster we can get you a fix. If we can't 
			reproduce a problem, there is little we can do to help you. </p>
		<p>Ideally, 
			the <a href="support/test_cases.html">test case</a> you send should be the same window you were editing 
			when the problem occurred (along with any supporting files needed to 
		compile it). If that is not possible (possibly because 
			you aren't allowed to send any code to a 3rd party), then you should 
			try to create a new, standalone test case that illustrates the same 
			problem. The best approach is to create a standalone test case by 
		removing all of the code that isn't relevant to the problem at hand 
		(e.g., keep deleting code until the problem goes away and then restore 
		that last code that was last deleted).</p>
		<p>Parsing problems can also be a side effect of the other 
		problems described in the <a href="#DoesNotWork">earlier FAQ entry here</a> 
		so check each of the suggestions there. Refreshing and rebuilding your 
		project using the <b>Project &gt; Clean</b> command can often help as can 
		cleaning your Eclipse "configuration" directory.</p>
		<h2 style="font-weight: bold;"><a name="OutOfMemoryError"></a>What 
			should I do if I encounter an OutOfMemoryError using WindowBuilder 
		Pro?</h2>
		<p>Make sure that you have Eclipse
			configured to use enough memory. 
			Begin by specifying the starting amount of memory (<b>-vmargs -Xms###m</b>)
      in your Eclipse startup command line (e.g., the
      target field within a Windows shortcut) or <b>eclipse.ini</b> file (in 
		your Eclipse root directory). If this is not specified,
      Eclipse's starting amount of memory is quite small (only 40 MB). You 
		should also specify the maximum amount of memory that Eclipse can 
		use (<b>-vmargs -Xmx###m)</b> and the maximum amount of perm space available (<b>-vmargs -XX:MaxPermSize=###m</b>).</p>
		<p>We typically recommend something like this (these setting are 
		independent of any of the startup settings that you might have in place):</p>
		<dl>
			<dd><b>-vmargs -XX:MaxPermSize=128m -Xms256m 
			-Xmx512m</b></dd>
		</dl>
		<p>An OutOfMemoryError is usually a side effect of something else, so 
			you should send your Eclipse ".log" file (found in your 
			&lt;workspace&gt;/.metadata directory) as well as any relevant test cases 
			to support. 
		</p>
		<p>You might try running Eclipse with the -debug command line 
		option. You can then press <b>Ctrl+Break</b> in the console to look at 
		the thread dump which may show where the system is locking up and where 
		the memory is going. Send that thread dump to support</p>
		<h2 style="font-weight: bold;"><a name="NoSuchMethodError"></a><a name="NoClassDefFoundError"></a>What 
			should I do if I encounter an NoSuchMethodError or 
		NoClassDefFoundError using WindowBuilder Pro?</h2>
		<p>Start by checking your Eclipse ".log" file (found in your 
		<b>&lt;workspace&gt;/.metadata directory</b>). If the error references one of 
		your classes or methods, check that your classpath properly references 
		the class you are trying to use. Also check that your class is properly 
		compiled (no red <font color="#ff0000"><b>X</b></font>'s) and that a <b>
		.class</b> file exists in your projects <b>/bin</b>
directory. A mismatch between the JDK used to compile your code and the JVM used 
		to run Eclipse can also manifest itself as a <span style="font-weight: bold;">NoClassDefFoundError </span>
problem. For example, if you compile your code using JDK 1.5 or 1.6 and
then run your Eclipse using a 1.4 or 1.5 JVM, you can have this
problem. If the error refers to a custom widget, you should also
check that your component does not trigger an exception during its
initialization (which can manifest itself as a <span style="font-weight: bold;">NoClassDefFoundError</span>).&nbsp;Try <b>
		refreshing</b> and <b>cleaning</b> your project using the <b>Project &gt; 
		Clean...</b> or <b>Project &gt; Build Project</b> commands. If that does not help, send a test case to
		support.</p>
		<p>If the error references a base Eclipse 
		method or class, this means that you have the wrong version of 
		WindowBuilder Pro 
		loaded for the version of Eclipse you are using. WindowBuilder Pro is 
		trying to access a method or class that simply does not exist in your Eclipse 
		distribution. Delete the WindowBuilder Pro feature and plugin directories 
		and then download and install the correct version of&nbsp; WindowBuilder 
		Pro for the version of Eclipse you are 
		using.</p>
		<p>If the error refers to a method or class in a WindowBuilder Pro class, this means that you have a serious Eclipse 
		configuration problem, and that one or more of the WindowBuilder Pro plugins are not being loaded properly. If a plugin does not load, all of 
		its methods will be unreachable, and any attempts to access them will 
		trigger a NoSuchMethodError or NoClassDefFoundError. This problem can usually be fixed by 
		cleaning your Eclipse "configuration" directory as described in this <a href="#DoesNotWork">earlier FAQ entry</a>.</p>
		<h2 style="font-weight: bold;"><a name="UnsupportedClassVersionError"></a>What 
			should I do if I encounter an UnsupportedClassVersionError using 
		WindowBuilder Pro?</h2>
		<p>An UnsupportedClassVersionError is usually caused by attempting to 
		run code compiled against a later JRE with an IDE using an earlier JRE. 
		Typically, you will see this when trying to use a class (such as a 
		custom widget) that has been compiled against JDK 1.6 within a version 
		of Eclipse launched with JDK 1.5.</p>
		<p>Two solutions are possible: you may either recompile the class using 
		JDK 1.5, or you can tell Eclipse to run using JDK 1.6 by modifying its 
		startup parameters as follows (use your path to JDK 1.6 on your system):</p>
		<blockquote>
			<p>-vm C:\jdk1.6.0_21\bin\java.exe</p>
		</blockquote>
		<h2 style="font-weight: bold;"><a name="UnsatisfiedLinkError"></a>What should I do 
			if I encounter an UnsatisfiedLinkError when launching my SWT 
			application?</h2>
		<p>As stated in the product docs and tutorial, the 
			Eclipse SWT DLL (which can be found in the <b>$ECLIPSE$\plugins\org.eclipse.swt.win32_x.x.x\os\win32\x86\</b> 
			directory or in the <b>org.eclipse.swt.win32.win32.x86_3.x.x.jar 
		file</b>) needs to be on your path. Placing it into your 
			<b>windows/system32</b> directory is the easiest thing to do.</p>
		<p>For Linux, you need to locate the corresponding Eclipse 
		SWT *.so files contained in the SWT GTK plugin.</p>
				<h2 style="font-weight: bold;"><a name="Linux"></a>How should 
				WindowBuilder Pro be configured to 
		work on Linux?</h2>
		<p>To use WindowBuilder Pro in Linux, we recommend that you use an 
		official JDK from Sun, as using the GPL version of the java is not recommended. 
		Here are some setup instructions for using Sun's java with Fedora Core and Debian. Note that 
		use of a non-Sun JDK can result in Eclipse locking up.<br>
		<br>
		Using Sun's Java with Fedora Core:</p>
		<ol>
			<li>Download and Unpack Sun's JDK .bin format.<br>
&nbsp;</li>
			<li>If you wish to use java on the command line or with other 
			programs besides eclipse add the following to your /etc/profile <br>
			<br>
			JAVA_HOME = &lt;path_to_jdk&gt;<br>
			PATH= $PATH:$JAVA_HOME/bin<br>
			Export JAVA_HOME PATH<br>
&nbsp;</li>
			<li>Install Sun's java as alternative<br>
			#/usr/sbin/alternatives -install /usr/bin/java java &lt;path_to_jdk&gt; 2<br>
&nbsp;</li>
			<li>Switch to the new alternative<br>
			#/usr/sbin/alternatives -config java<br>
			Select option 2<br>
&nbsp;</li>
			<li>Test <br>
			#/usr/sbin/alternatives -display java </li>
		</ol>
		<p>You should see java pointing to the Sun JDK.<br>
		<br>
		Using Sun's Java with Debian:</p>
		<ol>
			<li>Download Sun JDK in .bin format<br>
&nbsp;</li>
			<li>fakeroot make-jpkg &lt;jdk&gt;.bin<br>
			This creates a .deb package.<br>
&nbsp;</li>
			<li>sudo dpkg -i &lt;jdk&gt;.deb<br>
&nbsp;</li>
			<li>Test <br>
			#java -version.</li>
		</ol>
		<h2 style="font-weight: bold;">
		<a name="SuSELinux"></a>What should I do if I have problems running 
		under SuSE Linux?</h2>
		<p>If you have a problem running WindowBuilder Pro on Linux SuSE 
		10.3 such as Eclipse crashing and/or working incorrectly, or your my log 
		files contains something like &quot;xcb_xlib.c:42: xcb_xlib_lock: Assertion 
		`!c-&gt;xlib.lock'&quot; and/or &quot;/usr/lib/Eclipse: No such file or directory&quot;, 
		please try to add the following into you profile:</p>
		<blockquote>
			<p>LIBXCB_ALLOW_SLOPPY_LOCK=1<br>
			export LIBXCB_ALLOW_SLOPPY_LOCK. </p>
		</blockquote>
		<h2 style="font-weight: bold;">
		<a name="LinuxFlashing"></a>How can I prevent the preview window from 
		flashing under Linux using Metacity</h2>
		<p>In order to create the graphics that you see in the 
		design view, WindowBuilder Pro creates an off screen window containing the 
		various widgets and they takes a screen snapshot of them. This works 
		very well under Windows, OSX and some versions of Linux. Recent versions 
		of the Metacity window manager (more recent than 2.1.4), however, 
		have been modified/"fixed" to disallow windows to be opened off screen. 
		This forces the preview window to appear on screen leading to an 
		annoying flashing effect any time you make a change. The solution is to 
		disable the Metacity "fully_onscreen" constraint by patching the Metacity source code and rebuilding and installing the patched 
		version into your system. <br>
		<br>
		Here are the steps to follow:</p>
		<ol>
			<li>
			Download the Metacity source code from
			<a href="ftp://ftp.gnome.org/pub/gnome/sources/metacity/">
			ftp://ftp.gnome.org/pub/gnome/sources/metacity/</a></li>
			<li>
			Unpack the source code tarball into any temporary 
			directory.</li>
			<li>
			Chdir into this directory (with the unpacked code).</li>
			<li>
			Find window.c file and open it with your 
			favourite texteditor.</li>
			<li>
			Find a line with "window-&gt;require_fully_onscreen 
			= TRUE;"</li>
			<li>
			Replace it with "window-&gt;require_fully_onscreen = 
			FALSE;"</li>
			<li>
			Save the changes and close the editor.</li>
			<li>
			Open a terminal and chdir into the directory with 
			the source code (nice if you have already done this)</li>
			<li>
			Run "./configure".</li>
			<li>
			Run "make all".</li>
			<li>
			Make sure that steps 9 &amp; 10 completed without 
			errors.</li>
			<li>
			Become root (or execute the next command via "sudo" 
			depending on the Linux you are running)</li>
			<li>
			Run "make install" (or "sudo make install").</li>
			<li>
			Save your work and close any application you are 
			working with.</li>
			<li>
			End your session (or press Ctrl-Alt-Delete to 
			restart the x-server) and log in again.</li>
			<li>
			You are done!</li>
		</ol>
				</td>
			</tr>
		</table>









</body></html>
